-
Notifications
You must be signed in to change notification settings - Fork 207
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better support for status and initial support for partstat #1271
Conversation
I can confirm that this works as intended. Will take discussion back to #580 though. |
khal/khalendar/event.py
Outdated
@property | ||
def _status_str(self) -> str: | ||
if self.status == 'CANCELLED': | ||
statusstr = ' ' + self.symbol_strings['cancelled'] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to make a case against adding a leading space, or at least to make this configurable. Such a leading space should really be part of the format specification, though I realise it's currently not possible to work with conditionals there.
However, {status: <1}
will probably suit anyone better when the status symbol is to be used mid-field, whereas adding all the statuses to the end of the line won't make a difference anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
965c9b6
to
03e1ae5
Compare
config file now takes several addresses per account, but we expect that only one will match. |
@WhyNotHugo sorry for bombing you with review requests, feel free to ignore them. |
This PR doesn't cover yet formatting events by their status as it's a bit more difficult to get this looking the same in khal and ikhal. I'd prefer to merge this without that now, because rebasing against master is becoming tiresome (not especially this branch, but keeping several non-merged features branches around is getting tiring). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I understand correctly, the CALDAV:calendar-user-address-set
property allows querying the address of the owner of a calendar.
This should enable fetching the email address of the calendar owner via vdirsyncer.
Perhaps treating this as calendar metadata might be more future compatible?
@WhyNotHugo interesting. We should definitively support that, but probably only as a default. At least one of my caldav servers has an email address set that nobody sends email to. |
91b59be
to
2d37e0c
Compare
2d37e0c
to
d508e18
Compare
No description provided.